Smart cards are cards with embedded circuitry that provide a variety of functionality. Currently, smart cards may be used for credit or debit cards, SIMs for mobile phones, authorization cards for pay television, access-control cards, electronic wallets, public transport payment cards, and for a wide variety of other purposes. One quickly growing use for smart cards is in the area of digital identification. Smart cards are becoming common as tools for verifying and maintaining digital identification information. The reason for the use of smart cards in the area of digital identification is that the cards are engineered to be secure and tamper resistant.
In general, current smart cards are about the size of a credit card (although the card may be bigger or smaller depending on its function). The type and amount of embedded circuitry on a smart card also varies. A typical smart card in use today will include around 512 bytes of volatile storage (e.g., RAM), a slightly greater amount of non-volatile storage (e.g., around 16 kilobytes of EPROM), and a small microprocessor.
Accordingly, software written for current smart cards has to be compact in order to execute in current smart cards' limited computing resource environments. An example of a software framework for developing and executing applications for current smart cards is Sun Microsystem's Java® Card 2.2 technology (“Java Card”) (Java® is registered trademarks owned by Sun Microsystems, Inc., Mountain View, Calif.). To make use of the limited resources on current smart cards, Java Card provides an operating framework that includes an abridged version of the standard Java® virtual machine (e.g., the Java Card virtual machine (“JCVM”)). The JCVM implements a subset of the standard Java virtual machine instructions.
Because the JCVM does not contain all the standard Java® virtual machine instructions, applications for current smart cards are compacted into a specialized CAP file format. Compressed applets or “CAP” files are traditional Java® class files that have been compressed by translating standard Java virtual machine instructions into a more compact format. This is done by stripping unnecessary information from the Class files from which the CAP files are generated and reducing the number of commands and functions available to be called.
In a Java®-based environment, stripping unnecessary information can include substituting long strings of characters for tokens (e.g., a few characters or a small number representing a longer string). For example, an original Class file may make an external call to the “JavaCard.Framework.Shareable” library. A conversion tool translates that call so that all instances of the external “JavaCard.Framework.Shareable” call are replaced with a token (usually only a single byte in size) that references that particular library. Thus, the original command containing 28 characters (or 28 bytes) is significantly reduced. Accordingly, the size of a CAP file is much smaller than an ordinary Class file. Note that after converting the Class file to CAP format, in order to keep external calls (and names) consistent among multiple applications, the mapping of the call to the token may be stored in a separate file (such as a JCA or EXP file). Then, when other applications are translated, those applications can use the same tokens for specific calls. In this way, only one copy of the external resource with its tokenized name needs to be stored in the smart card environment.
Moreover, since smart cards have limited resources, the smart card's virtual machine generally supports a subset of the instructions a normal virtual machine would support. Accordingly, during the translation process, instructions in a Class format (e.g., Java® byte code) are translated into similar CAP instructions. Often, multiple Class file instructions have to be reduced to a single instruction to perform a similar function. Generally, compacting commands reduces functionality. In many cases, a Class file instruction is simply not supported by a smart card. In those cases, the conversion tool may terminate because it cannot complete a translation, or it may simply ignore the command, throw an exception, prompt the user to change the Class file instruction, enter a corresponding CAP file instruction, or launch a debugging interface. Because of the limited number of commands supported by current smart cards, the size of the applications is considerably reduced.
To further reduce the size of the virtual machine on a smart card, the conversion tool may take additional steps to preprocess a file before converting it into CAP format. Basically, this means that some of the tasks that current Java® virtual machines perform are done prior to converting the file into CAP format. For example, in a standard Java® environment, static variables are typically initialized either when a program is launched or the variable is used. In the Class-to-CAP conversion process, static variables are preinitialized and symbolic references in the Class file are resolved before the file is converted. Moreover, to further reduce the resources required to execute CAP files, Java® Classes are checked to make sure they are properly formed and use only the subset of the Java® programming language that is properly supported by the smart card platform before converting a Class file to CAP format. This preprocessing keeps the Java virtual machine on current smart cards as small as possible by reducing the amount of error-checking and error-handling the smart cards need to perform.
After a Java® Class file has been converted into CAP format, in some cases, additional files, such as a Java® Class Assembly (“JCA”) file or export (“EXP”) file, may also be created. As mentioned above, these extra files contain public interface information about the Classes in the CAP file and provide information about the fields and methods in each CAP file and any of its associated files.
Once a Class file has been converted into CAP format, the CAP-formatted file (“CAP file”) can be downloaded to a current smart card using an on-card installer program and hardware.
Going forward, however, a next generation of smart cards is being developed that provide far greater computing resources than current smart cards. (Note: although the next generation smart cards have far greater computing resources than current smart cards (e.g., “legacy smart cards), the computing resources are still relatively limited when compared to other computing devices (e.g., notebook computers, cell phones, personal computers, etc.)). Because of the greater computing resources, the next generation smart cards can provide a more sophisticated computing environment than the legacy smart cards. As a result, software developers have begun developing more sophisticated software for the next generation smart card.
For example, Sun Microsystem's next generation Java Card technology takes advantage of the next generation smart cards' greater resources by, among other things, creating a virtual machine that can execute Java® Class files. By providing support for Java® Class files, the next generation Java Card virtual machine expands what a smart card can do. For instance, the new virtual machine can implement a much larger set of Java® Class libraries (e.g., Strings), can execute applications in a multi-threaded environment, and can make available many of Java® access control mechanisms. Basically, the next generation Java Card environment provides support for many, if not all, of Java's® traditional features.
Moreover, by providing support for Java® Class files, application development costs for the new smart card platform are reduced since applications can be developed with traditional development tools and ported to the new platform without drastic changes to the application design or code. In this sense, the next generation Java Card platform drastically reduces the need for CAP files.
In fact, as it stands, problems can arise when attempts are made to execute applications in CAP format on a next generation smart card. For example, CAP files have been designed to run as single-threaded applications. As a result, applications on the legacy smart cards have been designed to share common resources (e.g., application data units or certain system files). In next generation smart card environments, sharing a single common resource among multiple applications causes the JCVM to slow down because the JCVM has to perform additional checking to flag the unsafe storing of references. For example, an application may contain a reference to an APDU object that is now in use by a different application. The JCVM performs checks to flag these bad references. Otherwise, an application could use its stored reference to access information in the APDU object even though another application has assumed control of it.
Beyond just runtime performance issues, another problem with supporting CAP files or other legacy applications on next generation smart cards is the development and resource costs of implementing the equivalent of two virtual machines, one to support CAP files and another to support Class files. Although next generation smart cards have more computing resources than legacy smart cards, they generally do not have sufficient resources to implement the two different virtual machines (or the equivalent thereof).
A proposed solution is to simply update legacy applications to be compatible with the next generation smart card. Unfortunately, the cost and time involved in updating and upgrading CAP files and other legacy applications can be quite significant. Software users may not have the time to wait for new software releases, and, even so, they may not be able to afford the updated applications once released. Similarly, software developers may not put a high priority on updating older applications. Hence, it may be months or years (or maybe never) before an application is updated.
Overall, the current solutions for enabling both legacy and non-legacy applications to be executed on a next generation smart card are not satisfactory.
The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.